Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Making the best use of dynamic objects

There are a few simple rules for making the best use of dynamic objects without incurring memory leaks:

Keep your interactions short. The longer the span between when you create an object and when your application is done using it, the greater the likelihood that you will forget to delete it and that you will never detect this until your application dies in production because of a memory leak. This span really has less to do with time than with the organization of your procedures. If the architecture of your application is clear about how dynamic objects are created and when they are deleted, then you will do well. If your code is inconsistent about this, then you will have a very difficult time identifying whether you’ve cleaned up after yourself or not.
Always use widget pools. Remember that the CREATE WIDGET-POOL statement at the top of a procedure is not a Progress default, or even a default for all procedures you build in the AppBuilder. It is simply a convention observed by a few template files for some kinds of procedures the AppBuilder creates. Create your own templates and your own convention and stick to it.
Make a practice of always deleting every object as soon as you are done with it, even if you are using widget pools. A widget pool in a procedure can accumulate an enormous number of unused objects if you wait until the procedure goes away or until the widget pool is explicitly deleted. The widget pool mostly serves as a backup mechanism to get rid of objects you somehow forget to delete explicitly or to help you organize the deletion of related groups of objects. If you have a procedure that creates a large number of objects and then deletes them all at once, then go ahead and use the DELETE WIDGET-POOL statement for that purpose. In that case, be as conscientious about deleting every widget pool as soon as you are done with it as you should be with individual objects.
If you create named persistent widget pools, be very clear in your application architecture about making sure that some procedure deletes them, unless they are used only for objects that always must live for the duration of the session. Also, make sure that you never delete a pool while its objects are still being used.
If your procedure is immediately going to create another object of the same type as one you are done with, then go ahead and reuse the same object without deleting it and creating a new one. This is generally faster, even if you are changing all the characteristics of the object. But don’t leave piles of objects lying around in your code on the off chance that you might want to reuse them.
Test your application rigorously with an eye to memory usage before you ship it to your customers.